1. Field of the Invention
The present invention is directed to distributed transaction processing systems. More particularly, the present invention is directed to methods and apparatus for enhancing the performance of communications between nodes in a distributed transaction processing system that supports the ISO/IEC OSI TP communications protocol.
2. Description of the Prior Art
On-line transaction processing (OLTP) is a technology that has been used successfully for business-critical applications by large enterprises for many years. With OLTP, users at terminals send messages to application programs, and these in turn update databases in real time. This is in contrast to batch or queued processing of transactions where the transactions are processed at a later time.
An example of an OLTP application is an airline reservation system. When a travel agent sends a request to reserve a seat on a plane, a database is updated accordingly, and a confirmation message is sent back to the agent's terminal. All of the tasks are part of a single transaction, and many agents can perform transactions at the same time. OLTP systems are typically used in environments that support large numbers of users, all accessing the same database, with hundreds and sometimes thousands of transactions taking place each second. The systems are typically based on large enterprise servers that can provide the performance, reliability, and data integrity demanded by these environments.
A transaction may be thought of as a set of actions performed by a transaction processing system wherein the actions together exhibit the properties of Atomicity, Consistency, Isolation, and Durability (ACID). The following definitions are given in Transaction Processing: Concepts and Techniques, by Jim Gray and Andreas Reuter, Morgan Kaufmann Publishers, Inc., 1993, p. 6:
Atomicity. A transaction's changes to the state are atomic; either all happen or none happen. These changes include database changes, messages, and actions on transducers.
Consistency. A transaction is a correct transformation of the state. The actions taken as a group do not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program.
Isolation. Even though transactions execute concurrently, it appears to each transaction, T, that other transactions execute either before T or after T, but not both.
Durability. Once a transaction completes successfully, (commits), the state of the data is changed to reflect the successful completion of the transaction, and the state of the data will survive system failures.
To maintain the properties identified above, at the beginning of processing a transaction, a transaction processing application program typically invokes some form of begin-transaction function to indicate that processing of a transaction has begun. This operation is typically logged to an audit file to demarcate the operations associated with the particular transaction. Following the begin-transaction function, the other functions associated with the application-defined transaction are performed and are also logged to an audit file. If all operations associated with a transaction complete successfully, a commit function is invoked to make permanent any state changes that have occurred as a result of the transaction. The commit operation is logged to the audit file to indicate that all operations have completed successfully. If an error occurs during processing of the transaction and a commit operation is not performed, a rollback function is invoked to undo the effects of the operations performed to that point in processing the transaction.
Distributed Transaction Processing (DTP) is a form of on-line transaction processing that allows a single transaction to be performed by multiple application programs that access one or more databases on one or more computers across a network. This type of transaction, in which multiple application programs cooperate, is called a distributed transaction. Using DTP, for example, related databases at regional and branch locations can be synchronized. DTP also facilitates transaction processing across multiple enterprises. For example, DTP can be used to coordinate the computers of manufactures and suppliers, or to coordinate the computers of enterprises in related industries, such as the travel agency, airline, car rental, and hotel industries.
Transaction processing in a distributed environment can be either non-global or global. In a non-global transaction, the same work takes place as in a traditional transaction, but the work is distributed in a client/server manner. For example, a travel agent may request an airline reservation via a client application program that has a graphical user interface. The client application program communicates with a server application program that manages the reservation database. The server application program updates the database, commits or aborts its own work, and returns information to the client application program, which notifies the travel agent.
A global transaction consists of multiple, coordinated database updates, possibly occurring on different computers. Global transactions are used when it is important that all databases are synchronized so that either all updates are made or none are made. Continuing with the previous example, the travel agent may also need to reserve a rental car and hotel room. The customer who is traveling wants to make sure that all reservations are coordinated; if a flight is unavailable, the hotel and car reservations are not needed. For the purpose of illustrating a global transaction, the airline, car, and hotel databases are on different transaction processing systems.
The global transaction begins when the travel agent requests the reservation from a workstation client application program with a graphical user interface. The client program contacts three server application programs on different transaction processing systems. One server program books a flight, another reserves a car, and the third makes a hotel reservation. Each of the server application programs updates its respective database. The transactions processed by each of the server application programs may be referred to as subordinate transactions of the global transaction. A global transaction manager coordinates the updates to the three databases, and a subordinate transaction manager on each of the individual transaction processing systems coordinates locally with the server application programs. The server application programs return information to the client application program.
A major advantage of global transaction processing is that tasks that were once processed individually are processed as a group, the group of tasks being the global transaction. The database updates are made on an all-or-nothing basis. For example, if an airline seat is not available, the hotel and car reservations are not made. Thus, with a global transaction, tasks that were once performed independently may be coordinated and automated.
As with non-global transactions, global transactions must possess the ACID properties. In order to preserve the ACID properties for a global transaction, the commit processing is modified to a two-phase commit procedure. Under a two-phase commit, a global transaction manager first requests that each of the subordinate transaction managers prepare to commit their updates to the respective databases. If all the local transaction managers respond that they are prepared to commit, the global transaction manager sends a commit request to the local transaction managers. Thus, the two parts of the two-phase commit process are (i) prepare to commit the database updates, and (ii) commit the database updates. If any one of the transaction managers is unable to prepare to commit, the entire global transaction is aborted and each transaction manager performs a rollback function to undo the processing that may have occurred up to that point. In short, the two-phase commit process ensures that multiple databases participating in a single global transaction are synchronized--either all database updates requested by the global transaction are made or, in the event of system or component failure, none are made. Two-phase commit guarantees global data integrity and preserves the ACID properties in a DTP environment.
An industry consortium of users and vendors, known as X/Open.TM., has developed a model architecture for DTP, referred to as the X/Open Distributed Transaction Processing model. The X/Open DTP model is a software architecture that allows multiple application programs to share resources provided by multiple resource managers, and allows their work to be coordinated into global transactions. The X/Open DTP model comprises a number of components, application programming interfaces, and communications interfaces.
FIG. 1 illustrates a client system 10 and a server system 12 both constructed in accordance with the X/Open DTP model architecture. Referring to the client system 10 as an illustrative example, the components of the X/Open DTP model include an application program (AP) 14, one or more resource managers (RMs) 16, a Transaction Manager (TM) 18, and a Communications Resource Manager (CRM) 20.
An Application Program (AP), such as client application program 14, is a user-defined software component that defines global transaction boundaries and specifies actions that constitute global transactions. It also provides access to one or more resources that are required by a transaction. In a global transaction, two or more APs perform their individual functions which, when combined, make up the global transaction. One of the APs will be the transaction coordinator, that is, the AP that starts and finishes the global transaction. The other APs will be subordinate.
A Resource Manager (RM) 16 provides access to a resource for the AP 14. The X/Open DTP model permits multiple resource managers. Database management systems and file access systems are examples of system software components that act as RMs.
The APs begin and end transactions under the control of the Transaction Manager (TM) 18. The TM 18 is a system software component that assigns transaction identifiers to global transactions, monitors their progress, coordinates their completion, and coordinates failure recovery. The TM enforces the transaction property of atomicity. In a global transaction, the TM adheres to the two-phase commit transaction processing protocol.
The CRM 20 controls communication between the AP 14 and other APs (e.g., AP 40) that are participating in global transactions, as well as between the TM 18 and TMs on separate data processing systems (e.g., the TM of system 12).
The X/Open DTP model provides a number of standard application programming interfaces that enable application programs to interact with system components to conduct global transactions. These application programming interfaces include one or more AP-RM interfaces 22, an AP-TM interface 24, an AP-CRM interface 26, an RM-TM interface 28, and a TM-CRM interface 30.
The AP-RM interfaces 22 provide the AP 14 with access to resources (such as databases) through their respective RMs 16. These interfaces are not specifically defined by the X/Open DTP model, as a number of different resources can exist on a system. Examples of AP-RM interfaces include the Structured Query Language (SQL) and the Indexed Sequential Access Method (ISAM).
The AP-TM interface 24 is provided by the TM 18 to define global transaction boundaries. The AP-TM interface is also referenced as the TX interface. Further information on the TX interface is available in Distributed Transaction Processing: The TX (Transaction Demarcation) Specification, X/Open Company Limited, U.K., (1992). The TX interface is described in somewhat greater detail below.
The AP-CRM 26 interfaces are provided by the CRM 20 to the AP 14. The X/Open DTP model supports the following three AP-CRM interfaces: the TXRPC interface, the XATMI interface, and the CPI-C interface. Each of these interfaces can be used to enable communication between APs that utilize the same interface. Although the XATMI interface is discussed below in somewhat greater detail, further information on the XATMI interface is available in Distributed Transaction Processing: The XATMI Specification, X/Open Company Limited, U.K., (1993)(hereinafter "the XATMI Specification"), which is incorporated herein by reference in its entirety.
The TM-RM interface 28 is used for purposes of transaction control (preparing, committing, or rolling-back). The TM-RM interface 28 is described further in XA Interface, Distributed Transaction Processing: The TX (Transaction Demarcation) Specification, X/Open Company Limited, U.K. (1992). The TM-CRM interface 29 is described further in X/Open Preliminary Specification--Distributed Transaction Processing: The XA+ Specification, X/Open Company Limited, U.K. (1993).
In addition to the foregoing application programming interfaces, systems that implement the X/Open DTP model can communicate with each other using an industry standard communications protocol know as Open Systems Interconnection (OSI) Transaction Processing (TP) (ISO/IEC 10026) ("the OSI TP Standard"), all parts of which are hereby incorporated by reference in their entireties. The OSI TP Standard defines a machine independent protocol that supports communications between computers in a transaction processing system. An industry standard CRM-OSI TP programming interface, called XAP-TP, provides an interface between a CRM 20 and an OSI TP protocol machine 34 that conforms to the OSI TP Standard. ISO/IEC 10026-3, Information Technology--Open Systems Interconnection--Distributed Transaction Processing--Part 3: Protocol Specification ("the OSI TP Protocol Specification") defines the state transitions and protocols that a conformant OSI TP protocol machine must generate in processing OSI TP service requests in accordance with the OSI TP Standard. The XAP-TP programming interface is specified in X/Open ACSE/Presentation: Transaction Processing API (XAP-TP) CAE specification ("the XAP-TP Specification"). The XAP-TP Specification defines the interface, including functions, parameters, and errors, that controls the use of a conformant OSI-TP protocol machine. An implementation of lower layer communication protocols 36 handles the low-level communication chores needed to send information between systems 10 and 12 via a network 38. These lower layer protocols can, for example, be OSI or TCP/IP. The X/Open DTP model does not define an interface to these lower layers.
FIG. 2 is a block diagram illustrating the process structure of a prior art implementation of the XAP-TP and OSI TP components 32, 34 of the system of FIG. 1. The XAP TP component 32' of this implementation operates in accordance with the XAP-TP Specification, and comprises an XAP-TP REQ component 42 for handling calls from the CRM 20 to the OSI TP protocol machine 34' and an XAP-TP RCV component 43 for handling incoming requests received from a peer node (not shown). The OSI TP protocol machine 34', which conforms to the OSI TP Protocol Specification, comprises an HLS FD component 44, with an associated queue 45, a Multiple Association Control Facility (MACF) protocol machine 46, a Channel Protocol Machine 47, a Single Association Control Facility (SACF) protocol machine 48, and a Commitment, Concurrency and Recovery (CCR) component 49.
The CRM calls OSI TP services using the XAP-TP interface. Calls to OSI TP services are passed through the XAP-TP REQ component 42. Data received from a peer node passes through the OSI TP protocol machine 34' and is placed on a queue in the XAP-TP RCV component 43. The CRM periodically polls the XAP-TP RCV component 43 to retrieve data from the queue.
The HLS FD component 44 is a high level scheduler that implements a queuing mechanism. Any requests issued to the OSI TP protocol machine 34' by the CRM 20, and any data and/or requests received from a peer node via the OSI TP protocol machine 34' are placed on the queue 45 of the HLS FD 44.
As specified in the OSI TP Protocol Specification, operation of the OSI TP protocol machine 34' is controlled by two lower level protocol machines, the Multiple Association Control Facility (MACF) protocol machine 46, and the Single Association Control Facility (SACF) protocol machine 49. The MACF protocol machine 46 maps OSI TP services onto other functional capabilities to control and manage the establishment, commitment and recovery of transactions. The SACF protocol machine 49 maintains consistent behavior on each association. It consists of procedures for dialogue establishment and for managing an association while not in a dialogue, as well as for passing service requests through to the lower layer protocols 36. Operation of the MACF protocol machine 46 is specified in the OSI TP Protocol Specification in the form of a MACF state table that defines "events" for each available OSI TP service. For each event, the MACF state table specifies the actions to be performed by the protocol machine depending upon its current state, and if a transition to another state is to occur, the state table specifies that next state. Similarly, operation of the SACF protocol machine 49 is specified in the OSI TP Protocol Specification in the form of a SACF state table. The structure of this table is similar to the MACF state table in that actions and state transitions are specified for each SACF operation. Additional details of the operation of standard MACF and SACF protocol machines are provided in the OSI TP Standard.
The CPM (channel protocol machine) includes the necessary provisions to establish and terminate channel associations used during recovery. The CCR provides support for commitment, rollback and recovery functions when required. Additional details of the operation of the CPM and CCR components of a standard OSI TP protocol machine are also provided in the OSI TP Standard.
As the preferred embodiment of the present invention relates particularly to distributed transaction processing systems in which the CRM component implements the XATMI AP-CRM interface, further details of the XATMI interface follow.
The XATMI interface relies principally on the following API requests supported by the TX interface:
tx.sub.-- begin()--a demarcation function that indicates that subsequent work performed by the calling AP is in support of a global transaction;
tx.sub.-- commit()--a demarcation function that commits all work done on behalf of the current global transaction; and
tx.sub.-- rollback()--a demarcation function that rolls back all work done on behalf of the current global transaction. Further details of the TX interface can be found in Distributed Transaction Processing: The TX (Transaction Demarcation) Specification, X/Open Company Limited, U.K., (1992).
The XATMI API provides a set of function calls, collectively referred to as the tp*() function calls, that can be called to perform various functions. Table 1 is a list of these functions, callable from any C language application program:
TABLE 1 ______________________________________ Service Requests (Function Calls) of the XATMI API. Name Description ______________________________________ Typed Buffer Functions tpalloc() Allocate a typed buffer. tpfree() Free a typed buffer. tprealloc() Change the size of a typed buffer. tptypes() Determine information about a typed buffer. Functions for Writing Service Routines tpservice() Template for service routines. tpreturn() Return from a service routine. Functions for Dynamically Advertising Service Names tpadvertise() Advertise a service name. tpunadvertise() Unadvertise a service name. Functions for Request/Response Services tpacall() Send a service request. tpcall() Send a service request and synchronously await its reply. tpcancel() Cancel a call descriptor for an outstanding reply. tpgetrply() Get a reply from a previous service request. Functions for Conversational Services tpconnect() Establish a conversational service connection. tpdiscon() Terminate a conversational service connection abortively. tprecv() Receive a message in a conversational connection. tpsend() Send a message in a conversational connection. ______________________________________
Each of the foregoing XATMI API requests has a formal syntax that specifies the format and arguments of each request. The formal syntax for each request is specified in the XATMI Specification.
The XATMI interface supports typed buffers through the typed buffer functions listed above. A typed buffer contains data and has associated with it a type and possibly a subtype, that indicate the meaning or interpretation of the data. An AP calls tpalloc() to allocate a typed buffer of a specified type and subtype, can call tprealloc() to increase its size, and must eventually call tpfree() to dispose of it. A receiver of a typed buffer can call tptypes() to determine the type and subtype of a buffer as well as its size.
Generally, there are two types of services supported by the XATMI interface--request/response services and conversational services. In the request/response service paradigm, requests can be issued to services in two ways: synchronously or asynchronously. The tpcall() function sends a request to a specified service, and returns any response in an application-defined typed buffer. The call to tpcall() returns after any expected response arrives. The tpacall() function also sends a request to a specified service, but it returns without waiting for the service's response, thereby letting the requester do additional work while the service routine processes its request. The tpgetrply() function waits to receive a service reply corresponding to a specified request, and returns the response in an application-defined typed buffer. A requester not wanting to receive a reply to a particular request can use the tpcancel() function, which informs the CRM that any response should be silently discarded.
In the conversational service paradigm, a requester invokes a service routine and converses with it in an application-defined manner. Conversational communication with a service is initiated by calling the tpconnect() function. The service name and application data can be passed to the service as parameters of the call. A descriptor is returned that the requester subsequently uses to refer to the newly established connection. tpsend() and tprecv() are used by APs to exchange data over an open connection. Normally, a connection is terminated by the CRM after the service returns by calling tpreturn(). If, however, a requester wishes to terminate a connection prematurely, the tpdiscon() function is used.
The functions tpservice() and tpreturn() are used to facilitate the writing of service routines in server application programs. A service routine is invoked from implementation-specific dispatching code contained within a server. Handling of the communication path is independent of the service and is the responsibility of the CRM. tpservice() is the template for writing service routines, and can be used both for request/response services, as well as for conversational services. tpreturn() is used to send a service's reply message. If an AP is waiting for a reply as a result of either a tpcall(), tpgetrply(), or tprecv(), then a successful call to tpreturn() by the service will place the reply in the receiving AP's buffer.
When a requesting AP uses either tpacall(), tpcall(), or tpconnect() to interact with a particular service, it passes a service name identifier to the service AP as a parameter to the call. When servers are started, they advertise the set of services that they offer by name, in an application-specific manner. tpadvertise() is used by a server to advertise a new service that it offers. The function has two parameters: the service name identifier and the actual C language routine that the server must invoke whenever a requesting AP requests that service by name. A server can use the tpunadvertise() function to unadvertise a service.
Application programs (APs) make calls to the TM and CRM components of a distributed transaction processing system, via the respective TX and XATMI interfaces, to initiate and execute global transactions. In general, a global transaction is processed as follows. The client application program executing on one system uses a tx-begin() primitive of the TX interface to start a global transaction. Thereafter, the client application program uses various XATMI primitives, such as tpcall(), tpacall(), and tpconnect(), to call various services provided by one or more server application programs executing on the same or other systems. The server application programs may use local RMs to update databases in response to the calls made by the client application program. When the work is done, the client application program will use the tx.sub.-- commit() primitive of the TX interface to initiate the two-phase commit process and to coordinate that process among the client's TM and the TMs of the various service application programs involved in the transaction. Specifically, the initiating TM (the one that received the tx.sub.-- begin() )will communicate with all the other TMs via OSI TP to request approval to commit and update the databases. If all agree, the database will be updated. If any do not agree, then a rollback function is performed to return all databases to the state they were in before the transaction began. If the client application program and/or any of the server application programs reside on different computer systems, the two systems will communicate with each other using their respective CRMs, which are built on a foundation of OSI TP. As mentioned above, OSI TP provides services and protocols that assist the two-phase commit process and communication between systems. The OSI TP implementations on each system in turn operate across lower layer services and protocols that can, for example, be OSI or TCP/IP.
Further according to the X/Open DTP model, the primitives (i.e., function calls) of the XATMI API are mapped to the services of the OSI TP protocol through an abstraction layer referred to as the XATMI Application Service Element (XATMI ASE). The XATMI-ASE defines how the primitives in the XATMI interface (e.g., tpcall, tpacall, tpsend, etc.) are mapped to the services of the OSI TP protocol.
First, each of the primitives of the XATMI interface described above is mapped to a service primitive of the XATMI ASE. Table 2 summarizes the set of XATMI-ASE services used by the relevant XATMI interface primitives.
TABLE 2 ______________________________________ XATMI-ASE Services Used By XATMI Interface Primitives XATMI Interface Client Server Primitives Role Role XATMI-ASE Services ______________________________________ tpcall() .circle-solid. XATMI-CALL req (XATMI-REPLY ind or XATMI-FAILURE ind) tpacall() .circle-solid. XATMI-CALL req tpgetrply() .circle-solid. XATMI-REPLY ind or XATMI-FAILURE ind tpcancel() .circle-solid. XATMI-CANCEL req tpservice() .circle-solid. XATMI-CALL ind or XATMI-CONNECT ind tpreturn() .circle-solid. XATMI-REPLY req or XATMI-FAILURE req tpconnect() .circle-solid. XATMI-CONNECT req tpdiscon() .circle-solid. XATMI-DISCON req tpsend() .circle-solid. .circle-solid. XATMI-DATA req (XATMI-REPLY ind or XATMI-DISCON ind or XATMI-FAILURE ind) tprecv() .circle-solid. .circle-solid. XATMI-DATA ind and (XATMI-REPLY ind or XATMI-DISCON ind or XATMI-FAILURE ind) ______________________________________
Similarly, the primitives of the TX interface are mapped to XATMI-ASE services, as shown in Table 3.
TABLE 3 ______________________________________ XATMI-ASE Services Used By TX Interface Primitives TX Interface Primitives XATMI-ASE Services ______________________________________ tx.sub.-- commit() XATMI-PREPARE req XATMI-READY ind XATMI-COMMIT req XATMI-COMMIT ind XATMI-DONE req XATMI-COMPLETE ind tx.sub.-- rollback() XATMI-ROLLBACK req XATMI-DONE req XATMI-COMPLETE ind ______________________________________
As further specified in the XATMI Specification, each of the services of the XATMI-ASE maps to one, or a combination of, OSI TP services. Both client role mappings and server role mappings are provided. For example, the XATMI-ASE services, XATMI-CALL req and XATMI-REPLY ind, map to multiple OSI TP services as follows:
______________________________________ XATMI-ASE Services Map (Client) No. OSI TP Services ______________________________________ XATMI-CALL req 1 TP-BEGIN-DIALOGUE req [TP-DEFER-END-DIALOGUE req] TP-DATA req TP-GRANT-CONTROL req 2 TP-BEGIN-DIALOGUE req TP-DATA req TP-END-DIALOGUE req XATMI-REPLY ind 3 TP-DATA ind TP-GRANT-CONTROL ind XATMI-REPLY ind 4 TP-DATA ind (cont.) TP-END-DIALOGUE ind ______________________________________
Mappings for the other XATMI-ASE service primitives are provided in the XATMI Specification.
The XAP-TP programming interface, described briefly above, provides the interface between the XATMI-ASE service calls issued by a CRM, and the corresponding OSI TP service calls to which they must be mapped in an OSI TP protocol machine. As shown by the foregoing examples, some of the XATMI-ASE service primitives map to a combination of more than one OSI TP service. For example, the XATMI-ASE service primitive, XATMI-CALL req, maps to a sequence of three OSI TP service calls, TP-BEGIN-DIALOGUE req, TP-DATA req, and TP-GRANT-CONTROL req. Thus, according to the XAP TP Specification and OSI TP Protocol Specification, the XAP-TP interface must be called three successive times in order to execute the XATMI-CALL req service primitive of the XATMI-ASE, i.e., once for each OSI TP service call to which it maps. Moreover, according to the OSI TP Protocol Specification, each of the OSI TP service calls is processed by the OSI TP protocol machine independently--one at a time.
FIG. 3 illustrates the manner in which a CRM and a conformant OSI TP protocol machine operate to execute a function call of the XATMI interface in accordance with the standard OSI TP Protocol Specification. Using the X/Open DTP model system illustrated in FIG. 1 as an example, at step 50, the Application Program 14 on the client node 10 of the distributed transaction processing system issues a tpcall() function call to the CRM 20. The tpcall() function call is mapped in the CRM 20 to the XATMI-CALL req primitive of the XATMI-ASE. As illustrated in Table 2, the XATMI-CALL req primitive of the XATMI-ASE maps to the following sequence of OSI TP service requests: TP.sub.13 BEGIN.sub.-- DIALOGE.sub.-- REQ, TP.sub.-- DATA.sub.-- REQ, and TP.sub.-- GRANT CONTROL.sub.-- REQ. At step 52, the CRM 20 calls the OSI TP protocol machine 34 through the XAP-TP interface 32, requesting that a TP.sub.-- BEGIN.sub.-- DIALOGE.sub.-- REQ be issued to the server node (i.e., peer) 12. At step 54, the OSI TP protocol machine 34 processes the TP.sub.-- BEGIN.sub.-- DIALOGE.sub.-- REQ request and then returns control to the CRM 20. At step 56, the lower layer protocols send an OSI TP PDU to the peer comprising a TP.sub.-- BEGIN.sub.-- DIALOGUE.sub.-- RI.
Next, at step 58, the CRM 20 calls the OSI TP protocol machine 34 a second time, again using the XAP TP interface 32, to request that a TP.sub.-- DATA.sub.-- REQ be issued to the peer 12. At step 60, the OSI TP protocol machine 34 processes the request and returns control to the CRM 20. At step 62, the CRM 20 calls the OSI TP protocol machine 34 a third time via the XAP-TP interface 32, requesting that the OSI TP protocol machine 34 issue a TP.sub.-- GRANT.sub.-- CONTROL.sub.-- REQ to the peer. The OSI TP protocol machine 34 processes the request at step 64. At step 66, the lower layer protocols send another OSI TP PDU to the peer comprising U.sub.-- ASE.sub.-- RI and TP.sub.-- GRANT.sub.-- CONTROL.sub.-- RI indications.
As FIG. 3 illustrates, according to the XAP-TP Specification and OSI TP Protocol Specification, the CRM 20 is required to make calls to the OSI TP protocol machine 34, via XAP-TP 32, three separate times in order to perform the services required by the XATMI-CALL req primitive of the XATMI-ASE. Each of these calls enters the OSI TP protocol machine 34 separately. For each call, the OSI TP protocol machine 34 makes the necessary state transitions, and then enters a protocol encoder to encode appropriate OSI-TP PDUs, as described in the OSI TP Protocol Specification. These PDUs are eventually sent to the network 38 via the lower layer protocols 36, as illustrated at steps 56 and 66.
The reason that higher-level services, such as the XATMI-CALL req of the XATMI-ASE, are broken down into more granular service primitives within the OSI TP protocol machine is that, as mentioned above, the standard OSI TP protocol machine, as specified in the OSI TP Protocol Specification, must support multiple AP-CRM programming interfaces--the XATMI interface described above, the TXRPC interface, the CPI-C interface, and others not yet defined. Combinations of the granular service primitives of the OSI TP Protocol Specification are executed, in sequence, as necessary to perform the higher level services of each AP-CRM interface.
In practice, the granular nature of the service primitives of the OSI TP Protocol Specification can result in increased system overhead that adversely affects the performance and throughput of any implementation of the OSI TP Protocol Specification. For example, as the flow diagram of FIG. 3 illustrates, because of the granular nature of the OSI TP Protocol Specification, execution of a single XATMI-ASE service request, such as XATMI-CALL req, requires three separate calls to a standard OSI TP protocol machine via the XAP TP interface. The system must cross the process boundary between the user process (i.e., the software processes executing the functions of the AP, TM, and CRM) and the OSI TP process (i.e., the software processes executing the functions of the OSI TP protocol machine) multiple times. Numerous calls across process boundaries in a software implementation of a system can seriously affect performance of the system.
Some distributed transaction processing systems may only support one of the three available AP-CRM programming interfaces. For example, a system may only support the XATMI interface. Nevertheless, the OSI TP Protocol Specification was designed with sufficient granularity to support many AP-CRM interfaces, and the overhead imposed by that design cannot be avoided with a fully compliant OSI TP protocol machine. Accordingly, there is a need for methods and apparatus for optimizing the operation of an OSI TP based protocol machine for use in a particular AP-CRM interface environment, without affecting the conformance of the system to the OSI TP Protocol Specification. The present invention satisfies this need.